The goal of this document is to enable the creation of network environments where an end-user can take delivery of new equipment (compliant to this recommendation), connect it to their network, and configure it for use, with a minimum amount of human interaction. Specifically, the interaction ought to be limited to acknowledging the equipment’s existence (for security reasons), assigning operational names to the signals the equipment generates, and defining any grouping relationships the signals might have with other existing signals. Technical configuration of the equipment in regards to timing, signal transport, and routing interactions is automated by the behaviors and management systems described in this recommendation.
Media Nodes shall be connected to at least one Media Network, and may have connections to two or more media networks. If more than one Media Network is used then the active-active redundancy model of SMPTE ST 2022-7 shall be supported by the Media Node.
Media Nodes may have zero or more connections to the Control Network. This Control Network may be a single subnet or a routed environment. If a Media Node has more than one connection to the Control Network, those connections shall, by default, be configured to form a single (link-aggregated) network
interface using LACP (IEEE 802.1AX) and are considered a single "interface."
Media Nodes shall not bridge or forward traffic from one network to another under any circumstance.
Each network interface of a Media Node shall have a unique MAC address and a different IP Host Address from the other interfaces on the Media Node.
The network interfaces to each Media Network shall also be on separate subnets from other Media Network(s). Media Nodes with more than one connectionto the same Media Network shall allow the same subnet across the connections to the same Media Network, but shall also allow each interface to be on a different subnet.
Media Nodes shall support ICMP "Echo Request" (a/k/a PING) on all network interfaces.
By default, Media Nodes shall not assume the role of PTP grandmaster in normal operation.
Media Nodes which connect to more than one Media Network should carefully choose the best source of PTP across all of their Media Network interfaces.
Media Nodes shall use the PTP parametric values and domain number specified in the System API defined in AMWA IS-09. If the System API is not available, stored values from the last successful operational experience should be used.
Media Nodes should ensure that their internal timebase maintains usable stability during transitions between grandmasters. In the holdover case, Media Nodes should continue to meet their interface specifications for several minutes (20 minutes is a suggested target).
Media Nodes shall implement IEEE 802.1AB "LLDP" (Link-Layer Discovery Protocol) protocol on each Media Network connection in order to identify themselves to the Media Network switches. Where possible, the LLDP information transmitted on the interfaces of a device should include the MAC address of the transmitting port.
Media Nodes shall report their interface information as required under AMWA IS-04 NMOS Node API. In particular, the "port_id" field of each interface object in the node resource must contain the MAC address of the related interface. LLDP on Control Network interfaces is encouraged but not mandated.
IETF RFC 2131 DHCP (Dynamic Host Configuration Protocol) service shall be available on the Control Network and the Media Networks, either directly or via DHCP Relay Agents.
IETF RFC 2131 DHCP service shall be available on the Control Network and the Media Networks, either directly or via DHCP Relay Agents.
The DHCP service shall provide host configuration information to the Media Node for the network interfaces which request it. The table above enumerates the minimum DHCP options which shall be available to all Media Nodes. Facilities are permitted to support additional options as needed.
Media Nodes shall request option 12 (wherein the DHCP server provides a hostname) and if the DHCP server returns a hostname with option 12 the Media Node shall use it. The Media Node shall create its own unique host name in the event that the DHCP server does not reply with a hostname under option 12. Using a textual representation of the MAC address as part of the name is one way to accomplish this.
Media Nodes shall support DHCP option 81, wherein the DHCP server can request the client to return its FQDN to the DHCP server.
The Network Environment shall include one or more unicast DNS servers; the addresses of these servers shall be distributed to Media Nodes via DHCP option 6. Media Nodes may supplement or override the DHCP option 6 information with user configuration.
Media Nodes may attempt to register their hostname in DNS; however system security settings might prevent this action from succeeding. In systems which are secured in this manner, the DHCP server may be configured to perform a secure DNS Dynamic Update on behalf of the Media Node.
If more than one DNS server is advertised (or configured) to a media node, it is the responsibility of the environment to provide consistent information across the multiple DNS servers.
IPv4 Unicast Routing shall be available between and amongst hosts on the Control Network and the Media Network(s). The Broadcast Controller shall be able to communicate with any network interface on any Media Node, and any Media Node shall be able to communicate with the IS-04 registry services and broadcast controllers via unicast from any of its management-enabled network interfaces - Media or Control.
Control Network interfaces, if present, shall be on a separate subnet from Media Network interfaces.
IETF RFC 2131 DHCP (Dynamic Host Configuration Protocol) service shall be available on the Control Network and the Media Networks, either directly or via DHCP Relay Agents.
PTP service compliant to IEEE 1588-2008 and compliant to the profile defined in SMPTE ST 2059-2 shall be available on each Media Network. PTP service is neither required nor prohibited on the control network. Media Nodes are not required to use PTP from the control network for any purpose, even in systems where it is present.
All Network-provided PTP services across all networks shall comply with the frequency accuracy provisions of SMPTE ST 2059-2. Where multiple potential Leader clocks are implemented, these should be derived from a consistent source of time and shall be within an absolute timing accuracy of +/-100ms to International Atomic Time (TAI) when the PTP timescale is in use. Typically, GPS-locked PTP is far tighter than this requirement.